UNICORE - Globus Interoperability: Getting the Best of Both Worlds

This paper describes software developed at the Research Centre Jülich to demonstrate the feasibility of Grid interoperability between UNICORE (Uniform Interface to Computer Resources) [1] and Globus [2] without changes to any of the systems. UNICORE user requests, like job submission, status query, and output retrieval had to be mapped to the corresponding Globus mechanisms. Another significant topic was the integration of the Globus security infrastructure into the UNICORE architecture. The functionality of this prototype has been demonstrated successfully on SC2001 in Denver. 1 Motivation There has been a substantial progress in developing Grid technologies in the recent years [3]. At universities and research centers world-wide scientists work on the evolution of Grid computing. Even if the way differs in many cases one of the principal goals of all those projects is the same: to give users access to distributed resources. Different projects focus on different aspects and it is only natural to combine them. Both Globus and UNICORE provide a Grid infrastructure which gives users access to distributed resources. Globus can be characterized as a toolkit that allows the development of Grid applications using the rich set of Globus services. UNICORE represents a vertically integrated solution focusing on uniform access to distributed computing resources. UNICORE is developed by a consortium of German universities, research laboratories, and software companies. It is funded in part by the German Ministry for Education and Research (BMBF). The work presented here has been carried out in cooperation between Argonne National Laboratory and Research Centre Jülich. UNICORE acts as a client to access selected Globus resources, allowing job submission, status queries, data staging, and output retrieval. In addition, the objective was to achieve the goal without changes to Globus and UNICORE. 2 UNICORE & Globus architectural concepts We restrict the description of the two architectures to the core concepts related to our work. Especially components needed to manage multi-site jobs – like co-allocation used by Globus or job dependencies and data staging in UNICORE – are not covered. For a detailed description of the infrastructures of UNICORE and Globus see [4] and [5] respectively. 2.1 UNICORE UNICORE implements a three tier architecture consisting of user, server and target system tier. As shown in Figure 1 the user tier consists of the UNICORE client, a graphical user interface which enables users to prepare and manage UNICORE jobs. The client is a Java application that executes on the user’s personal workstation. A UNICORE job is created using the Job Preparation Agent (JPA), where the user specifies the actions to be performed, the resources needed and the system on which the job is to run. From this job description the UNICORE client generates an Abstract Job Object (AJO), which instantiates the class representing UNICORE’s abstract job model. The AJO is signed with the user’s certificate and sent to the Gateway, one of the two components of the server tier. The Gateway authenticates the user and transfers the AJO to the Network Job Supervisor (NJS). The NJS translates the abstract job represented by the AJO into a target system specific batch job using the Incarnation Database (IDB). The Gateway and NJS execute typically on dedicated secure systems behind a firewall. UNICORE’s communication endpoint is the Target System Interface (TSI), which is a daemon executing on the target system. It’s role is to interface with the local operating system and the local batch subsystem. User tier UNICORE client Job Preparation Agent X.509 User Certificate Abstract Job Object (AJO) AuthenticationJob Object (AJO) Authentication